fix(web): the CSV export sent a body on HEAD, dropped connections, an… - #723

…d truncated itself (#703)

Review findings on #703, which merged before these landed. Three of them are on the export route, and all three are the kind static analysis cannot see.

A HEAD RETURNED THE WHOLE FILE. _send, _send_json and _serve_static all end their write with if self.command != "HEAD". _send_csv did not, and do_HEAD delegates to do_GET -- so HEAD /api/timeline/export.csv answered with the header block plus 468 bytes of CSV. On a keep-alive connection those bytes are framed as the NEXT response: a same-origin response desync, not merely a wasted transfer, and a violation of RFC 9110 §9.3.2.

The first test written for this passed against the bug. http.client knows a HEAD carries no body and never reads one, so it reports an empty body whether or not the server sent bytes -- the test now reads a raw socket, and says why in its docstring.

THE ROUTE DROPPED CONNECTIONS. respond is what normally guarantees this server never answers a GET by raising: ApiRefusal becomes a 400, anything else a 500 envelope. The CSV branch does not go through it, so ?limit=abc propagated out of the handler -- the client saw a reset connection with no response, and a traceback of absolute source paths reached the stderr log_message is overridden to keep quiet. A first-run machine with no config.yaml did the same, where /api/timeline answers 200 with engine: "stopped". Wrapped now, answering the JSON envelope: the failure is not a file, and a browser handed a truncated download learns nothing.

THE EXPORT WAS SILENTLY TRUNCATED. It inherited the paged route's ?limit= -- default 200, ceiling 2000 -- and the file said nothing about it. A 5,000-event deployment exported its most recent 200 rows, to be handed to an auditor or a tax preparer as a complete record. The cap exists because the console POLLS the JSON route every 15 seconds; an export is a deliberate download, requested once. export_rows reads the whole scope, and the scope -- the operator's own choice of today/7d/all -- is what bounds it.

A SORT COLUMN THAT ORDERED NOTHING. sortable=("ts", ...) while the payload emits at, so ?sort=ts was accepted, echoed back as applied, and left every row where it was -- the exact failure refusing an unknown column exists to prevent. The pin for this rot already existed at test_api.py:526 and covered two routes; /api/timeline was simply not in it, and is now.

AN UNREADABLE LOG LOOKED LIKE AN IDLE ENGINE. read_log_window returns a LogWindow for every outcome and carries the result in status; that status was discarded, so a log that could not be read (permissions, a rotation race) yielded zero lines -- dropping every system row AND dropping system from the chips. In the CSV an auditor opens, that is indistinguishable from "the engine never ran". activity.py's own docstring names the failure: silently discarding input is how a feed comes to under-report reality while looking healthy. It now raises, and the route turns it into a stated failure. The except OSError around it was dead -- read_log_window catches its own -- while the call that does raise on a real deployment, load_config, sat outside it.

LEADING WHITESPACE SMUGGLED FORMULAS PAST, and a test pinned the gap open. " =cmd|..." is a legal coinbase_id out of an imported venue CSV and lands in a cell by itself; Sheets and LibreOffice trim before deciding whether a cell is a formula. The check now strips SPACES only -- a bare lstrip() consumes tab and carriage return, which are themselves triggers, and broke two existing tests when tried. \\n joins the trigger list.

TWO TESTS THAT PASSED FOR THE WRONG REASON. Removing csv_safe from nine of its ten cells left the whole suite green: only reference was pinned, so the module's load-bearing claim -- "applied to EVERY text cell, not to a list of the risky ones" -- was untested for nine columns including summary, which carries an imported notes field verbatim. And deleting the newest-first sort left the suite green too, because the fixtures seeded oldest-to-newest in the same order the sources are concatenated. Both are pinned now with scrambled fixtures and a whole-row export assertion, and both die under mutation, along with the HEAD guard and the export cap.

Smaller: an unrecognised ?kind= is collapsed to "every kind" rather than applied, so the plural typo no longer returns a page that looks like an empty deployment -- the outcome normalise_scope, which it sits beside, exists to never produce; the cap's docstring said the READ was bounded when it bounds the response slice (four unfiltered SELECTs underneath); and the export URL is built with URL/searchParams like every other URL in the client.

That last one was caught by the call-resolution scanner added in #701: URL was not in its browser-globals list, so the guard failed the build on its own author's new code. URL is a real browser API and now belongs to that list.

What & why

Tests-first evidence

• Tests written first, seen failing for the right reason

Gates (all must pass)

• uv run ruff check clean
• uv run mypy clean
• uv run pytest -q green

Scope check

• This PR touches a rail or a default classification — checked means it DOES;
  leave checked only if true, and if so: cite the source and open the discussion
  BEFORE review (CONTRIBUTING.md, "Governance: rulings vs. machinery").
• New dependency added (needs discussion first)